Chris Huff <chr### [at] maccom> wrote:

> In article <3aacf34b@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> I'm trying to use the proximity pattern in a normal.  However, MP0.7 
>> is telling me that it isn't finding a normal type.  I thought perhaps 
>> I needed to add something like bozo, but if I do it before, it balks 
>> at the proximity ("no } found, found proximity instead").  If I do it 
>> after, it breaks the other way.  It looks to me like the proximity 
>> pattern is recognized as a pattern but isn't *set* as the pattern, so 
>> when it gets to the end of the normal, it bombs.

> You were putting "bozo" alongside the proximity{} block? That won't 
> work, you can only specify a single pattern for a normal. When it 
> finishes parsing the first pattern and finds another one, of course it 
> gives an error.

I didn't think it would. I only added it because it kept saying "Normal type
not defined"

> Did you try commenting out the proximity{} block and using only bozo or 
> another pattern? I don't think the proximity pattern is the problem 
> here...
>>   normal_map
>>   {
>>     [0 .5 ]
>>     [0.19 .5 ]
>>     [.2 1 ]
>>     [.3 .5 ]
>>     [1  .5 ]
>>   }

> This isn't the syntax for normal_maps...you need to put a normal 
> modifier in the entries, not a float value. I suspect you want a 
> slope_map...but even then, this is the wrong syntax, slope_maps take 2D 
> vectors.

I know.  I was trying to take a pigment I made with a proximity and use it
in the normal instead.  I knew I'd have to jiggle the variables, but since
it didn't work at all...

In fact, this is the problem.  When I changed to a slope map, it worked. 
didn't do what I wanted, but it didn't crash. ;)

Thanks.

Geoff

Post a reply to this message